home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 304 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.7 KB

  1. Path: fido.asd.sgi.com!austern
  2. From: clamage@Eng.Sun.COM (Steve Clamage)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Inherent C++ problem??
  5. Date: 06 Feb 1996 11:40:20 PST
  6. Organization: Sun Microsystems Inc.
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <4f8adk$fn6@engnews1.Eng.Sun.COM>
  9. References: <199602060648.HAA19423@mail.pi.se>
  10. Reply-To: clamage@Eng.Sun.COM
  11. NNTP-Posting-Host: isolde.mti.sgi.com
  12. X-Original-Date: 6 Feb 1996 19:33:08 GMT
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBVAwUBMReus0y4NqrwXLNJAQH/8QH/X+sqT5jVVwIQquauZ6mbTYNNtcaTfvDN
  15.     JhiyU1FRWw0ZNIqFBqwD+Qh3iXwV/ls9v8oDqE0aSpSZMPW2QtUhog==
  16.     =MvkZ
  17. Originator: austern@isolde.mti.sgi.com
  18.  
  19. In article HAA19423@mail.pi.se, william.mc@pi.se (William McIlhagga) writes:
  20.  
  21. >1) The standard says that an implementation *may* get rid of some copy
  22. >constructors; it does not demand it. Thus the indeterminism lies in the fact
  23. >that the programmer does not know whether this has happened to their code,
  24. >unless the compiler is kind enough to say so (compilers are the strong
  25. >silent type, and don't usually tell you anything about what they're thinking)
  26.  
  27. >2) Removing copy constructors is intended as an optimisation. But
  28. >optimisations should never change the meaning of a program - that is, the
  29. >program should produce the same results with and without the optimisation.
  30. >Clearly, removing "irrelevant" copy constructors is a different kind of
  31. >thing altogether. 
  32.  
  33. >I think this part of the standard is a little dangerous. I accept that
  34. >removing copy constructors is a useful optimisation however (though I
  35. >haven't seen any benchmarks to show how big a speedup you get - perhaps
  36. >someone could post some to convince us all that it's worthwhile). There are
  37. >a few things that might improve the situation:
  38.  
  39. >1) if an implemention removes a copy constructor, the standard should demand
  40. >that it issues a warning message (if the user desires...). Though I guess
  41. >most people will turn this warning off after a couple of hours, so maybe
  42. >that's not so smart.
  43.  
  44. >2) the standard should include some specified way of switching off the
  45. >removal of copy constructors. If it's in the standard then it's
  46. >transportable, so no problems there. Perhaps some ugly #pragma or something?
  47.  
  48. The problem is not just that a copy constructor might be elided in code like
  49.     T t = T(x); // T is some type
  50. Whether the temp gets elided might depend on the optimization level that
  51. was set or whether debugging is turned on.
  52.  
  53. The compiler is also allowed to create extra temps where convenient.
  54.  
  55. In addition, unless you are EXTREMELY knowledgeable about very fine
  56. semantic details of C++, you will be unable to determine reliably where
  57. temps must be created according to the language semantics. Even if you
  58. have this deep knowledge, it takes a very careful analysis of even a
  59. simple expression like
  60.     x = a + b + c;
  61. to determine where (if anywhere) temps must be created. It depends on
  62. the parameter types of the functions called, which further depends on
  63. the way overloaded function calls are resolved.
  64.  
  65. I really don't think you want to get messages about every temp that
  66. was created and every optional temp that was omitted. I also don't think
  67. you want to try to tell the compiler where it should and where it should
  68. not omit unneeded temps.
  69.  
  70. Instead, the basic design rule is that program correctness should not
  71. depend on exactly how many temps get created. Even with the compiler
  72. options you are asking for, a program with such a dependence would be
  73. unmaintainable.
  74. ---
  75. Steve Clamage, stephen.clamage@eng.sun.com
  76. ---
  77. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  78.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  79.   in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
  80.